1. Technical Field
The present invention relates to software emulators and, more particularly, relates to testing of software emulators.
2. Description of Related Art
An emulator is generally a device that is built to work like another. An emulator can be hardware, software, or a combination thereof. For example, an emulator may be software running on one machine that is designed to emulate another type of computer. Likewise, an emulator may be designed to execute software that was written to run on another computer. Typically, one computer emulates another computer (i.e., a computer with a different instruction set architecture (ISA)). A computer's normal running mode, called native mode, is the operational state of the computer when the computer is executing programs from the computer's built-in instruction set (host machine “architecture”). In contrast, an emulation mode is the operational state of the computer while the computer is running a foreign program under emulation (using a “target machine architecture”). A foreign program is a program written in a different (foreign) ISA (i.e., the target ISA) than the host machine's ISA (i.e., the host ISA).
When an emulator is built, it is often necessary to test the emulator to determine the emulator's effectiveness. Typical and obvious methods of testing emulators have involved such strategies as: 1) forcing an emulated machine into a known state, executing a test program under emulation, and comparing a finished state vector in the emulator against a hand generated expected state vector; 2) forcing an emulated machine into a known state, executing a state program under emulation, and comparing the emulations finished state vector against the finished state vector of a previous version of the emulator (i.e., “known good” finish state vector)—in a practice commonly known as “regression testing”; 3) forcing an emulated machine to a known state, executing a test program under emulation, and comparing the finished state vector against the finished state vector of the program as run on the target machine architecture; and, 4) forcing an emulated machine into a known state, executing a random sequence of machine instructions under emulation, and comparing the emulator's finished state vector against the finished state vector of the same sequence as run on the target machine architecture.
The above approaches of testing emulators all require the test program to be run under emulation and the output of the emulation to be compared with something else—a hand generated prediction, output of another emulation run, etc. FIG. 1 is a diagram generally illustrating the above approaches to testing emulators. Among the disadvantages of the above approaches is the likelihood of clerical error. For example, when comparing the output of one emulation run against another emulation run one output file may easily be confused with another. Likewise, hand-generated predictions of the output state are subject to transcription errors. Furthermore, in certain non-Unix operating systems such as Multi-Programming Executive (“MPE”), the state vector may contain important information, which, unfortunately, varies from one execution to another. Such variation makes simple-minded comparisons of state vectors difficult. MPE is a multi-user operating system (OS) developed by Hewlett-Packard Company in the 1970's. The current version of MPE is POSIX compliant and supports UNIX function calls.
What is needed, therefore, is a method of testing emulators that does not involve such complex and error-prone state vector setup and such complexity and susceptibility to errors in the checking of results.